SherbyNet - /page/wikibook/entry.mu

Micron Document

<!DOCTYPE html>

<title>Reactor pattern</title>

</head>

<span id="openzim-page-title" class="mw-page-title-main"><span class="mw-page-title-main">Reactor pattern</span></span>

</h1>

</header>

<p>The <b>reactor</b> <a href="Software_design_pattern" title="Software design pattern">software design pattern</a> is an <a href="Event_handling" class="mw-redirect" title="Event handling">event handling</a> strategy that can respond to many potential service requests <a href="Concurrency_(computer_science)" title="Concurrency (computer science)">concurrently</a>. The pattern's key component is an <a href="Event_loop" title="Event loop">event loop</a>, running in a <i>single</i> <a href="Thread_(computing)" title="Thread (computing)">thread</a> or <a href="Process_(computing)" title="Process (computing)">process</a>, which <a href="Demultiplex" class="mw-redirect" title="Demultiplex">demultiplexes</a> incoming requests and dispatches them to the correct request handler.<sup id="cite_ref-Schmidt_1995_1-0" class="reference"><a href="#cite_note-Schmidt_1995-1"><span class="cite-bracket">[</span>1<span class="cite-bracket">]</span></a></sup>

</p><p>By relying on event-based mechanisms rather than <a href="Blocking_I/O" class="mw-redirect" title="Blocking I/O">blocking I/O</a> or multi-threading, a reactor can handle many concurrent <a href="I/O_bound" title="I/O bound">I/O bound</a> requests with minimal delay.<sup id="cite_ref-Devresse_2014_2-0" class="reference"><a href="#cite_note-Devresse_2014-2"><span class="cite-bracket">[</span>2<span class="cite-bracket">]</span></a></sup>

A reactor also allows for easily modifying or expanding specific request handler routines, though the pattern does have some drawbacks and limitations.<sup id="cite_ref-Schmidt_1995_1-1" class="reference"><a href="#cite_note-Schmidt_1995-1"><span class="cite-bracket">[</span>1<span class="cite-bracket">]</span></a></sup>

</p><p>With its balance of simplicity and <a href="Scalability" title="Scalability">scalability</a>, the reactor has become a central architectural element in several <a href="Server_(computing)" title="Server (computing)">server</a> applications and <a href="Software_framework" title="Software framework">software frameworks</a> for <a href="Computer_network" title="Computer network">networking</a>. Derivations such as the <b>multireactor</b> and <a href="Proactor_pattern" title="Proactor pattern">proactor</a> also exist for special cases where even greater throughput, performance, or request complexity are necessary.<sup id="cite_ref-Schmidt_1995_1-2" class="reference"><a href="#cite_note-Schmidt_1995-1"><span class="cite-bracket">[</span>1<span class="cite-bracket">]</span></a></sup><sup id="cite_ref-Devresse_2014_2-1" class="reference"><a href="#cite_note-Devresse_2014-2"><span class="cite-bracket">[</span>2<span class="cite-bracket">]</span></a></sup><sup id="cite_ref-Escoffier_2021_3-0" class="reference"><a href="#cite_note-Escoffier_2021-3"><span class="cite-bracket">[</span>3<span class="cite-bracket">]</span></a></sup><sup id="cite_ref-Garrett_2015_4-0" class="reference"><a href="#cite_note-Garrett_2015-4"><span class="cite-bracket">[</span>4<span class="cite-bracket">]</span></a></sup>

</p>

<div class="mw-heading mw-heading2"><h2 id="Overview">Overview</h2></div>

<p>Practical considerations for the <a href="Client%E2%80%93server_model" title="Client–server model">client–server model</a> in large networks, such as the <a href="C10k_problem" title="C10k problem">C10k problem</a> for <a href="Web_server" title="Web server">web servers</a>, were the original motivation for the reactor pattern.<sup id="cite_ref-Kegel_2014_5-0" class="reference"><a href="#cite_note-Kegel_2014-5"><span class="cite-bracket">[</span>5<span class="cite-bracket">]</span></a></sup>

</p><p>A naive approach to handle service requests from many potential endpoints, such as <a href="Network_socket" title="Network socket">network sockets</a> or <a href="File_descriptor" title="File descriptor">file descriptors</a>, is to listen for new requests from within an event loop, then immediately <a href="Read_(system_call)" title="Read (system call)">read</a> the earliest request. Once the entire request has been read, it can be processed and forwarded on by directly calling the appropriate handler. An entirely "iterative" server like this, which handles one request from start-to-finish per iteration of the event loop, is logically valid. However, it will fall behind once it receives multiple requests in quick succession. The iterative approach cannot scale because reading the request <a href="Blocking_(computing)" title="Blocking (computing)">blocks</a> the server's only thread until the full request is received, and I/O operations are typically much slower than other computations.<sup id="cite_ref-Devresse_2014_2-2" class="reference"><a href="#cite_note-Devresse_2014-2"><span class="cite-bracket">[</span>2<span class="cite-bracket">]</span></a></sup>

</p><p>One strategy to overcome this limitation is multi-threading: by immediately splitting off each new request into its own worker thread, the first request will no longer block the event loop, which can immediately iterate and handle another request. This "thread per connection" design scales better than a purely iterative one, but it still contains multiple inefficiencies and will struggle past a point. From a standpoint of underlying <a href="System_resource" title="System resource">system resources</a>, each new thread or process imposes <a href="Overhead_(computing)" title="Overhead (computing)">overhead</a> costs in <a href="Computer_memory" title="Computer memory">memory</a> and processing time (due to <a href="Context_switch" title="Context switch">context switching</a>). The fundamental inefficiency of each thread waiting for I/O to finish isn't resolved either.<sup id="cite_ref-Schmidt_1995_1-3" class="reference"><a href="#cite_note-Schmidt_1995-1"><span class="cite-bracket">[</span>1<span class="cite-bracket">]</span></a></sup><sup id="cite_ref-Devresse_2014_2-3" class="reference"><a href="#cite_note-Devresse_2014-2"><span class="cite-bracket">[</span>2<span class="cite-bracket">]</span></a></sup>

</p><p>From a design standpoint, both approaches <a href="Tight_coupling" class="mw-redirect" title="Tight coupling">tightly couple</a> the general demultiplexer with specific request handlers too, making the server code brittle and tedious to modify. These considerations suggest a few major design decisions:

</p>

<ol><li>Retain a single-threaded event handler; multi-threading introduces overhead and complexity without resolving the real issue of blocking I/O</li>

<li>Use an event notification mechanism to demultiplex requests only <i>after</i> I/O is complete (so I/O is effectively non-blocking)</li>

<li>Register request handlers as <a href="Callback_(computer_programming)" title="Callback (computer programming)">callbacks</a> with the event handler for better <a href="Separation_of_concern" class="mw-redirect" title="Separation of concern">separation of concerns</a></li></ol>

<p>Combining these insights leads to the reactor pattern, which balances the advantages of single-threading with high throughput and scalability.<sup id="cite_ref-Schmidt_1995_1-4" class="reference"><a href="#cite_note-Schmidt_1995-1"><span class="cite-bracket">[</span>1<span class="cite-bracket">]</span></a></sup><sup id="cite_ref-Devresse_2014_2-4" class="reference"><a href="#cite_note-Devresse_2014-2"><span class="cite-bracket">[</span>2<span class="cite-bracket">]</span></a></sup>

</p>

<div class="mw-heading mw-heading2"><h2 id="Usage">Usage</h2></div>

<p>The reactor pattern can be a good starting point for any concurrent, event-handling problem. The pattern is not restricted to network sockets either; hardware I/O, <a href="File_system" title="File system">file system</a> or <a href="Database" title="Database">database</a> access, <a href="Inter-process_communication" title="Inter-process communication">inter-process communication</a>, and even abstract <a href="Message_passing" title="Message passing">message passing</a> systems are all possible use-cases.

</p><p>However, the reactor pattern does have limitations, a major one being the use of callbacks, which make <a href="Program_analysis" title="Program analysis">program analysis</a> and <a href="Debugging" title="Debugging">debugging</a> more difficult, a problem common to designs with <a href="Inversion_of_control" title="Inversion of control">inverted control</a>.<sup id="cite_ref-Schmidt_1995_1-5" class="reference"><a href="#cite_note-Schmidt_1995-1"><span class="cite-bracket">[</span>1<span class="cite-bracket">]</span></a></sup> The simpler thread-per-connection and fully iterative approaches avoid this and can be valid solutions if scalability or high-throughput are not required.<sup id="cite_ref-6" class="reference"><a href="#cite_note-6"><span class="cite-bracket">[</span>a<span class="cite-bracket">]</span></a></sup>

</p><p>Single-threading can also become a drawback in use-cases that require maximum throughput, or when requests involve significant processing. Different multi-threaded designs can overcome these limitations, and in fact, some still use the reactor pattern as a sub-component for handling events and I/O.<sup id="cite_ref-Schmidt_1995_1-6" class="reference"><a href="#cite_note-Schmidt_1995-1"><span class="cite-bracket">[</span>1<span class="cite-bracket">]</span></a></sup>

</p>

<div class="mw-heading mw-heading3"><h3 id="Applications">Applications</h3></div>

<p>The reactor pattern (or a variant of it) has found a place in many web servers, <a href="Application_server" title="Application server">application servers</a>, and networking frameworks:

</p>

<ul><li><a href="Adaptive_Communication_Environment" title="Adaptive Communication Environment">Adaptive Communication Environment</a> (ACE)<sup id="cite_ref-Schmidt_1995_1-7" class="reference"><a href="#cite_note-Schmidt_1995-1"><span class="cite-bracket">[</span>1<span class="cite-bracket">]</span></a></sup></li>

<li><a href="EventMachine" title="EventMachine">EventMachine</a></li>

<li><a href="Netty_(software)" title="Netty (software)">Netty</a><sup id="cite_ref-Escoffier_2021_3-1" class="reference"><a href="#cite_note-Escoffier_2021-3"><span class="cite-bracket">[</span>3<span class="cite-bracket">]</span></a></sup></li>

<li><a href="Nginx" title="Nginx">Nginx</a><sup id="cite_ref-Garrett_2015_4-1" class="reference"><a href="#cite_note-Garrett_2015-4"><span class="cite-bracket">[</span>4<span class="cite-bracket">]</span></a></sup></li>

<li><a href="Perl_Object_Environment" title="Perl Object Environment">Perl Object Environment</a></li>

<li><a href="POCO_C%2B%2B_Libraries" title="POCO C++ Libraries">POCO C++ Libraries</a><sup id="cite_ref-POCO_Network_Programming_8-0" class="reference"><a href="#cite_note-POCO_Network_Programming-8"><span class="cite-bracket">[</span>7<span class="cite-bracket">]</span></a></sup></li>

<li><a href="Spring_Framework" title="Spring Framework">Spring Framework</a> (version 5 and later)<sup id="cite_ref-Stoyanchev_2016_9-0" class="reference"><a href="#cite_note-Stoyanchev_2016-9"><span class="cite-bracket">[</span>8<span class="cite-bracket">]</span></a></sup></li>

<li><a href="Tokio_(software)" title="Tokio (software)">Tokio</a></li>

<li><a href="Twisted_(software)" title="Twisted (software)">Twisted</a><sup id="cite_ref-Twisted_2024_10-0" class="reference"><a href="#cite_note-Twisted_2024-10"><span class="cite-bracket">[</span>9<span class="cite-bracket">]</span></a></sup></li>

<div class="mw-heading mw-heading2"><h2 id="Structure">Structure</h2></div>

<div class="gallerytext">UML 2 component diagram of a reactive application.<sup id="cite_ref-Schmidt_1995_1-8" class="reference"><a href="#cite_note-Schmidt_1995-1"><span class="cite-bracket">[</span>1<span class="cite-bracket">]</span></a></sup></div>

</li>

<div class="gallerytext">UML 2 sequence diagram of a reactive server.<sup id="cite_ref-Schmidt_1995_1-9" class="reference"><a href="#cite_note-Schmidt_1995-1"><span class="cite-bracket">[</span>1<span class="cite-bracket">]</span></a></sup></div>

</li>

</ul>

<p>A reactive application consists of several moving parts and will rely on some support mechanisms:<sup id="cite_ref-Schmidt_1995_1-10" class="reference"><a href="#cite_note-Schmidt_1995-1"><span class="cite-bracket">[</span>1<span class="cite-bracket">]</span></a></sup>

/* start https://en.wikipedia.org/ */

.mw-parser-output .glossary dt{margin-top:0.4em}.mw-parser-output .glossary dt+dt{margin-top:-0.2em}.mw-parser-output .glossary .templatequote{margin-top:0;margin-bottom:-0.5em}

/* end https://en.wikipedia.org/ */

</style>

</p>

<dt id="handle"><dfn>Handle</dfn></dt>

<dd>An identifier and interface to a specific request, with IO and data. This will often take the form of a socket, file descriptor, or similar mechanism, which should be provided by most modern operating systems.</dd>

<dt id="demultiplexer"><dfn>Demultiplexer</dfn></dt>

<dd>An event notifier that can efficiently monitor the <i>status</i> of a handle, then notify other subsystems of a relevant status change (typically an IO handle becoming "ready to read"). Traditionally this role was filled by the <a href="Select_(Unix)" title="Select (Unix)">select() system call</a>, but more contemporary examples include <a href="Epoll" title="Epoll">epoll</a>, <a href="Kqueue" title="Kqueue">kqueue</a>, and <a href="IOCP" class="mw-redirect" title="IOCP">IOCP</a>.</dd>

<dt id="dispatcher"><dfn>Dispatcher</dfn></dt>

<dd>The actual event loop of the reactive application, this component maintains the registry of valid event handlers, then invokes the appropriate handler when an event is raised.</dd>

<dt id="event_handler"><dfn>Event Handler</dfn></dt>

<dd>Also known as a request handler, this is the specific logic for processing one type of service request. The reactor pattern suggests registering these dynamically with the dispatcher as callbacks for greater flexibility. By default, a reactor does <i>not</i> use multi-threading but invokes a request handler within the same thread as the dispatcher.</dd>

<dt id="event_handler_interface"><dfn>Event Handler Interface</dfn></dt>

<dd>An abstract interface class, representing the general properties and methods of an event handler. Each specific handler must implement this interface while the dispatcher will operate on the event handlers through this interface.</dd>

</dl>

<div class="mw-heading mw-heading2"><h2 id="Variants">Variants</h2></div>

<p>The standard reactor pattern is sufficient for many applications, but for particularly demanding ones, tweaks can provide even more power at the price of extra complexity.

</p><p>One basic modification is to invoke event handlers in their own threads for more concurrency. Running the handlers in a <a href="Thread_pool" title="Thread pool">thread pool</a>, rather than spinning up new threads as needed, will further simplify the multi-threading and minimize overhead. This makes the thread pool a natural complement to the reactor pattern in many use-cases.<sup id="cite_ref-Devresse_2014_2-6" class="reference"><a href="#cite_note-Devresse_2014-2"><span class="cite-bracket">[</span>2<span class="cite-bracket">]</span></a></sup>

</p><p>Another way to maximize throughput is to partly reintroduce the approach of the "thread per connection" server, with replicated dispatchers / event loops running concurrently. However, rather than the number of connections, one configures the dispatcher count to match the available <a href="CPU_core" class="mw-redirect" title="CPU core">CPU cores</a> of the underlying hardware.

</p><p>Known as a multireactor, this variant ensures a dedicated server is fully using the hardware's processing power. Because the distinct threads are long-running event loops, the overhead of creating and destroying threads is limited to server startup and shutdown. With requests distributed across independent dispatchers, a multireactor also provides better availability and robustness; should an error occur and a single dispatcher fail, it will only interrupt requests allocated to that event loop.<sup id="cite_ref-Escoffier_2021_3-3" class="reference"><a href="#cite_note-Escoffier_2021-3"><span class="cite-bracket">[</span>3<span class="cite-bracket">]</span></a></sup><sup id="cite_ref-Garrett_2015_4-2" class="reference"><a href="#cite_note-Garrett_2015-4"><span class="cite-bracket">[</span>4<span class="cite-bracket">]</span></a></sup>

</p><p>For particularly complex services, where synchronous and asynchronous demands must be combined, one other alternative is the proactor pattern. This pattern is more intricate than a reactor, with its own engineering details, but it still makes use of a reactor subcomponent to solve the problem of blocking IO.<sup id="cite_ref-Escoffier_2021_3-4" class="reference"><a href="#cite_note-Escoffier_2021-3"><span class="cite-bracket">[</span>3<span class="cite-bracket">]</span></a></sup>

</p>

<ul><li><a href="C10k_problem" title="C10k problem">C10k problem</a></li>

<li><a href="Event-driven_programming" title="Event-driven programming">Event-driven programming</a></li>

<li><a href="Input/output" title="Input/output">Input/output</a></li>

<li><a href="Libevent" title="Libevent">libevent</a></li>

<li><a href="Reactive_programming" title="Reactive programming">Reactive programming</a></li></ul>

<p><b>Related patterns:</b>

</p>

<ul><li><a href="Active_object" title="Active object">Active object</a></li>

<li><a href="Observer_pattern" title="Observer pattern">Observer pattern</a></li>

<li><a href="Proactor_pattern" title="Proactor pattern">Proactor pattern</a>, which allows mixing synchronous & asynchronous event handling</li></ul>

<div class="mw-heading mw-heading2"><h2 id="Notes">Notes</h2></div>

/* start https://en.wikipedia.org/ */

.mw-parser-output .reflist{margin-bottom:0.5em;list-style-type:decimal}@media screen{.mw-parser-output .reflist{font-size:90%}}.mw-parser-output .reflist .references{font-size:100%;margin-bottom:0;list-style-type:inherit}.mw-parser-output .reflist-columns-2{column-width:30em}.mw-parser-output .reflist-columns-3{column-width:25em}.mw-parser-output .reflist-columns{margin-top:0.3em}.mw-parser-output .reflist-columns ol{margin-top:0}.mw-parser-output .reflist-columns li{page-break-inside:avoid;break-inside:avoid-column}.mw-parser-output .reflist-upper-alpha{list-style-type:upper-alpha}.mw-parser-output .reflist-upper-roman{list-style-type:upper-roman}.mw-parser-output .reflist-lower-alpha{list-style-type:lower-alpha}.mw-parser-output .reflist-lower-greek{list-style-type:lower-greek}.mw-parser-output .reflist-lower-roman{list-style-type:lower-roman}

/* end https://en.wikipedia.org/ */

</style><div class="reflist reflist-lower-alpha">

<li id="cite_note-6"><span class="mw-cite-backlink"><b><a href="#cite_ref-6">^</a></b></span> <span class="reference-text">That said, a rule-of-thumb in software design is that if application demands can potentially increase past an assumed limit, one should expect that someday they will.</span>

</li>

</ol></div></div>

<div class="mw-heading mw-heading2"><h2 id="References">References</h2></div>

/* start https://en.wikipedia.org/ */

.mw-parser-output cite.citation{font-style:inherit;word-wrap:break-word}.mw-parser-output .citation q{quotes:"\"""\"""'""'"}.mw-parser-output .citation:target{background-color:rgba(0,127,255,0.133)}.mw-parser-output .id-lock-free.id-lock-free a{background:url("./mw/Lock-green.svg")right 0.1em center/9px no-repeat}.mw-parser-output .id-lock-limited.id-lock-limited a,.mw-parser-output .id-lock-registration.id-lock-registration a{background:url("./mw/Lock-gray-alt-2.svg")right 0.1em center/9px no-repeat}.mw-parser-output .id-lock-subscription.id-lock-subscription a{background:url("./mw/Lock-red-alt-2.svg")right 0.1em center/9px no-repeat}.mw-parser-output .cs1-ws-icon a{background:url("./mw/Wikisource-logo.svg")right 0.1em center/12px no-repeat}body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .id-lock-free a,body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .id-lock-limited a,body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .id-lock-registration a,body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .id-lock-subscription a,body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .cs1-ws-icon a{background-size:contain;padding:0 1em 0 0}.mw-parser-output .cs1-code{color:inherit;background:inherit;border:none;padding:inherit}.mw-parser-output .cs1-hidden-error{display:none;color:var(--color-error,#d33)}.mw-parser-output .cs1-visible-error{color:var(--color-error,#d33)}.mw-parser-output .cs1-maint{display:none;color:#085;margin-left:0.3em}.mw-parser-output .cs1-kern-left{padding-left:0.2em}.mw-parser-output .cs1-kern-right{padding-right:0.2em}.mw-parser-output .citation .mw-selflink{font-weight:inherit}@media screen{.mw-parser-output .cs1-format{font-size:95%}html.skin-theme-clientpref-night .mw-parser-output .cs1-maint{color:#18911f}}@media screen and (prefers-color-scheme:dark){html.skin-theme-clientpref-os .mw-parser-output .cs1-maint{color:#18911f}}

/* end https://en.wikipedia.org/ */

</style><cite id="CITEREFSchmidt1995" class="citation book cs1"><a href="Douglas_C._Schmidt" title="Douglas C. Schmidt">Schmidt, Douglas C.</a> (1995). <a rel="nofollow" class="external text" href="https://www.dre.vanderbilt.edu/~schmidt/PDF/reactor-siemens.pdf">"Chapter 29: Reactor: An Object Behavioral Pattern for Demultiplexing and Dispatching Handles for Synchronous Events"</a> <span class="cs1-format">(PDF)</span>. In <a href="Jim_Coplien" title="Jim Coplien">Coplien, James O.</a> (ed.). <i>Pattern Languages of Program Design</i>. Vol. 1 (1st ed.). Addison-Wesley. <a href="ISBN_(identifier)" class="mw-redirect" title="ISBN (identifier)">ISBN</a> <bdi>9780201607345</bdi>.</cite></span>

</li>

<li id="cite_note-Devresse_2014-2"><span class="mw-cite-backlink">^ <a href="#cite_ref-Devresse_2014_2-0"><sup><i><b>a</b></i></sup></a> <a href="#cite_ref-Devresse_2014_2-1"><sup><i><b>b</b></i></sup></a> <a href="#cite_ref-Devresse_2014_2-2"><sup><i><b>c</b></i></sup></a> <a href="#cite_ref-Devresse_2014_2-3"><sup><i><b>d</b></i></sup></a> <a href="#cite_ref-Devresse_2014_2-4"><sup><i><b>e</b></i></sup></a> <a href="#cite_ref-Devresse_2014_2-5"><sup><i><b>f</b></i></sup></a> <a href="#cite_ref-Devresse_2014_2-6"><sup><i><b>g</b></i></sup></a></span> <span class="reference-text"><cite id="CITEREFDevresse2014" class="citation web cs1">Devresse, Adrien (20 June 2014). <a rel="nofollow" class="external text" href="https://indico.cern.ch/event/282910/contributions/645355/attachments/521441/719267/efficient_parallel_IO_on_multicore_arch2.pdf">"Efficient parallel I/O on multi-core architectures"</a> <span class="cs1-format">(PDF)</span>. <i>2nd Thematic CERN School of Computing</i>. CERN. <a rel="nofollow" class="external text" href="https://web.archive.org/web/20220808062914/https://indico.cern.ch/event/282910/contributions/645355/attachments/521441/719267/efficient_parallel_IO_on_multicore_arch2.pdf">Archived</a> <span class="cs1-format">(PDF)</span> from the original on 8 August 2022<span class="reference-accessdate">. Retrieved <span class="nowrap">14 September</span> 2023</span>.</cite></span>

</li>

<li id="cite_note-Escoffier_2021-3"><span class="mw-cite-backlink">^ <a href="#cite_ref-Escoffier_2021_3-0"><sup><i><b>a</b></i></sup></a> <a href="#cite_ref-Escoffier_2021_3-1"><sup><i><b>b</b></i></sup></a> <a href="#cite_ref-Escoffier_2021_3-2"><sup><i><b>c</b></i></sup></a> <a href="#cite_ref-Escoffier_2021_3-3"><sup><i><b>d</b></i></sup></a> <a href="#cite_ref-Escoffier_2021_3-4"><sup><i><b>e</b></i></sup></a></span> <span class="reference-text"><cite id="CITEREFEscoffierFinnegan2021" class="citation book cs1">Escoffier, Clement; Finnegan, Ken (November 2021). <span class="id-lock-registration" title="Free registration required"><a rel="nofollow" class="external text" href="https://www.oreilly.com/library/view/reactive-systems-in/9781492091714/ch04.html">"Chapter 4. Design Principles of Reactive Systems"</a></span>. <i>Reactive Systems in Java</i>. O'Reilly Media. <a href="ISBN_(identifier)" class="mw-redirect" title="ISBN (identifier)">ISBN</a> <bdi>9781492091721</bdi>.</cite></span>

</li>

<li id="cite_note-Garrett_2015-4"><span class="mw-cite-backlink">^ <a href="#cite_ref-Garrett_2015_4-0"><sup><i><b>a</b></i></sup></a> <a href="#cite_ref-Garrett_2015_4-1"><sup><i><b>b</b></i></sup></a> <a href="#cite_ref-Garrett_2015_4-2"><sup><i><b>c</b></i></sup></a></span> <span class="reference-text"><cite id="CITEREFGarrett2015" class="citation web cs1">Garrett, Owen (10 June 2015). <a rel="nofollow" class="external text" href="https://www.nginx.com/blog/inside-nginx-how-we-designed-for-performance-scale/">"Inside NGINX: How We Designed for Performance & Scale"</a>. <i>NGINX</i>. F5, Inc. <a rel="nofollow" class="external text" href="https://web.archive.org/web/20230820232851/https://www.nginx.com/blog/inside-nginx-how-we-designed-for-performance-scale/">Archived</a> from the original on 20 August 2023<span class="reference-accessdate">. Retrieved <span class="nowrap">10 September</span> 2023</span>.</cite></span>

</li>

<li id="cite_note-Kegel_2014-5"><span class="mw-cite-backlink"><b><a href="#cite_ref-Kegel_2014_5-0">^</a></b></span> <span class="reference-text"><cite id="CITEREFKegel2014" class="citation web cs1">Kegel, Dan (5 February 2014). <a rel="nofollow" class="external text" href="http://www.kegel.com/c10k.html">"The C10k problem"</a>. <i>Dan Kegel's Web Hostel</i>. <a rel="nofollow" class="external text" href="https://web.archive.org/web/20230906022635/http://www.kegel.com/c10k.html">Archived</a> from the original on 6 September 2023<span class="reference-accessdate">. Retrieved <span class="nowrap">10 September</span> 2023</span>.</cite></span>

</li>

<li id="cite_note-Bonér_2022-7"><span class="mw-cite-backlink"><b><a href="#cite_ref-Bonér_2022_7-0">^</a></b></span> <span class="reference-text"><cite id="CITEREFBonér2022" class="citation web cs1">Bonér, Jonas (15 June 2022). <a rel="nofollow" class="external text" href="https://www.reactiveprinciples.org/patterns/isolate-mutations.html">"The Reactive Patterns: 3. Isolate Mutations"</a>. <i>The Reactive Principles</i><span class="reference-accessdate">. Retrieved <span class="nowrap">20 September</span> 2023</span>.</cite></span>

</li>

<li id="cite_note-POCO_Network_Programming-8"><span class="mw-cite-backlink"><b><a href="#cite_ref-POCO_Network_Programming_8-0">^</a></b></span> <span class="reference-text"><cite class="citation web cs1"><a rel="nofollow" class="external text" href="https://pocoproject.org/slides/200-Network.pdf">"Network Programming: Writing network and internet applications"</a> <span class="cs1-format">(PDF)</span>. <i>POCO Project</i>. Applied Informatics Software Engineering GmbH. 2010. pp. <span class="nowrap">21–</span>22<span class="reference-accessdate">. Retrieved <span class="nowrap">20 September</span> 2023</span>.</cite></span>

</li>

<li id="cite_note-Stoyanchev_2016-9"><span class="mw-cite-backlink"><b><a href="#cite_ref-Stoyanchev_2016_9-0">^</a></b></span> <span class="reference-text"><cite id="CITEREFStoyanchev2016" class="citation web cs1">Stoyanchev, Rossen (9 February 2016). <a rel="nofollow" class="external text" href="https://spring.io/blog/2016/02/09/reactive-spring">"Reactive Spring"</a>. <i>Spring.io</i><span class="reference-accessdate">. Retrieved <span class="nowrap">20 September</span> 2023</span>.</cite></span>

</li>

<li id="cite_note-Twisted_2024-10"><span class="mw-cite-backlink"><b><a href="#cite_ref-Twisted_2024_10-0">^</a></b></span> <span class="reference-text"><cite class="citation web cs1"><a rel="nofollow" class="external text" href="https://docs.twisted.org/en/stable/core/howto/reactor-basics.html">"Reactor Overview"</a>. <i>twisted.org</i><span class="reference-accessdate">. Retrieved <span class="nowrap">28 July</span> 2024</span>.</cite></span>

</li>

</ol></div></div>

<div class="mw-heading mw-heading2"><h2 id="External_links">External links</h2></div>

<p><b>Specific applications:</b>

</p>

<ul><li><cite id="CITEREFAlexeev2012" class="citation book cs1">Alexeev, Andrew (30 March 2012). <a rel="nofollow" class="external text" href="https://aosabook.org/en/v2/nginx.html">"Chapter 14: nginx"</a>. In Brown, Amy; Wilson, Greg (eds.). <i>The Architecture of Open Source Applications</i>. Vol. 2. Lulu.com. <a href="ISBN_(identifier)" class="mw-redirect" title="ISBN (identifier)">ISBN</a> <bdi>9781105571817</bdi>.</cite></li></ul>

<p><b>Sample implementations:</b>

</p>

<ul><li><a rel="nofollow" class="external text" href="http://www.ddj.com/cpp/193101548">APR Networking & the Reactor Pattern</a></li>

<li><a rel="nofollow" class="external text" href="https://web.archive.org/web/20100726184112/http://today.java.net/article/2007/02/08/architecture-highly-scalable-nio-based-server">Architecture of a Highly Scalable NIO-Based Server</a></li></ul>

/* start https://en.wikipedia.org/ */

.mw-parser-output .hlist dl,.mw-parser-output .hlist ol,.mw-parser-output .hlist ul{margin:0;padding:0}.mw-parser-output .hlist dd,.mw-parser-output .hlist dt,.mw-parser-output .hlist li{margin:0;display:inline}.mw-parser-output .hlist.inline,.mw-parser-output .hlist.inline dl,.mw-parser-output .hlist.inline ol,.mw-parser-output .hlist.inline ul,.mw-parser-output .hlist dl dl,.mw-parser-output .hlist dl ol,.mw-parser-output .hlist dl ul,.mw-parser-output .hlist ol dl,.mw-parser-output .hlist ol ol,.mw-parser-output .hlist ol ul,.mw-parser-output .hlist ul dl,.mw-parser-output .hlist ul ol,.mw-parser-output .hlist ul ul{display:inline}.mw-parser-output .hlist .mw-empty-li{display:none}.mw-parser-output .hlist dt::after{content:": "}.mw-parser-output .hlist dd::after,.mw-parser-output .hlist li::after{content:" · ";font-weight:bold}.mw-parser-output .hlist dd:last-child::after,.mw-parser-output .hlist dt:last-child::after,.mw-parser-output .hlist li:last-child::after{content:none}.mw-parser-output .hlist dd dd:first-child::before,.mw-parser-output .hlist dd dt:first-child::before,.mw-parser-output .hlist dd li:first-child::before,.mw-parser-output .hlist dt dd:first-child::before,.mw-parser-output .hlist dt dt:first-child::before,.mw-parser-output .hlist dt li:first-child::before,.mw-parser-output .hlist li dd:first-child::before,.mw-parser-output .hlist li dt:first-child::before,.mw-parser-output .hlist li li:first-child::before{content:" (";font-weight:normal}.mw-parser-output .hlist dd dd:last-child::after,.mw-parser-output .hlist dd dt:last-child::after,.mw-parser-output .hlist dd li:last-child::after,.mw-parser-output .hlist dt dd:last-child::after,.mw-parser-output .hlist dt dt:last-child::after,.mw-parser-output .hlist dt li:last-child::after,.mw-parser-output .hlist li dd:last-child::after,.mw-parser-output .hlist li dt:last-child::after,.mw-parser-output .hlist li li:last-child::after{content:")";font-weight:normal}.mw-parser-output .hlist ol{counter-reset:listitem}.mw-parser-output .hlist ol>li{counter-increment:listitem}.mw-parser-output .hlist ol>li::before{content:" "counter(listitem)"\a0 "}.mw-parser-output .hlist dd ol>li:first-child::before,.mw-parser-output .hlist dt ol>li:first-child::before,.mw-parser-output .hlist li ol>li:first-child::before{content:" ("counter(listitem)"\a0 "}

/* end https://en.wikipedia.org/ */

</style><style data-mw-deduplicate="TemplateStyles:r1236075235">

/* start https://en.wikipedia.org/ */

.mw-parser-output .navbox{box-sizing:border-box;border:1px solid #a2a9b1;width:100%;clear:both;font-size:88%;text-align:center;padding:1px;margin:1em auto 0}.mw-parser-output .navbox .navbox{margin-top:0}.mw-parser-output .navbox+.navbox,.mw-parser-output .navbox+.navbox-styles+.navbox{margin-top:-1px}.mw-parser-output .navbox-inner,.mw-parser-output .navbox-subgroup{width:100%}.mw-parser-output .navbox-group,.mw-parser-output .navbox-title,.mw-parser-output .navbox-abovebelow{padding:0.25em 1em;line-height:1.5em;text-align:center}.mw-parser-output .navbox-group{white-space:nowrap;text-align:right}.mw-parser-output .navbox,.mw-parser-output .navbox-subgroup{background-color:#fdfdfd}.mw-parser-output .navbox-list{line-height:1.5em;border-color:#fdfdfd}.mw-parser-output .navbox-list-with-group{text-align:left;border-left-width:2px;border-left-style:solid}.mw-parser-output tr+tr>.navbox-abovebelow,.mw-parser-output tr+tr>.navbox-group,.mw-parser-output tr+tr>.navbox-image,.mw-parser-output tr+tr>.navbox-list{border-top:2px solid #fdfdfd}.mw-parser-output .navbox-title{background-color:#ccf}.mw-parser-output .navbox-abovebelow,.mw-parser-output .navbox-group,.mw-parser-output .navbox-subgroup .navbox-title{background-color:#ddf}.mw-parser-output .navbox-subgroup .navbox-group,.mw-parser-output .navbox-subgroup .navbox-abovebelow{background-color:#e6e6ff}.mw-parser-output .navbox-even{background-color:#f7f7f7}.mw-parser-output .navbox-odd{background-color:transparent}.mw-parser-output .navbox .hlist td dl,.mw-parser-output .navbox .hlist td ol,.mw-parser-output .navbox .hlist td ul,.mw-parser-output .navbox td.hlist dl,.mw-parser-output .navbox td.hlist ol,.mw-parser-output .navbox td.hlist ul{padding:0.125em 0}.mw-parser-output .navbox .navbar{display:block;font-size:100%}.mw-parser-output .navbox-title .navbar{float:left;text-align:left;margin-right:0.5em}body.skin--responsive .mw-parser-output .navbox-image img{max-width:none!important}@media print{body.ns-0 .mw-parser-output .navbox{display:none!important}}

/* end https://en.wikipedia.org/ */

</style></div><div role="navigation" class="navbox" aria-labelledby="Software_design_patterns225" style="padding:3px"><table class="nowraplinks mw-collapsible autocollapse navbox-inner" style="border-spacing:0;background:transparent;color:inherit"><tbody><tr><th scope="col" class="navbox-title" colspan="2"><style data-mw-deduplicate="TemplateStyles:r1239400231">

/* start https://en.wikipedia.org/ */

.mw-parser-output .navbar{display:inline;font-size:88%;font-weight:normal}.mw-parser-output .navbar-collapse{float:left;text-align:left}.mw-parser-output .navbar-boxtext{word-spacing:0}.mw-parser-output .navbar ul{display:inline-block;white-space:nowrap;line-height:inherit}.mw-parser-output .navbar-brackets::before{margin-right:-0.125em;content:"[ "}.mw-parser-output .navbar-brackets::after{margin-left:-0.125em;content:" ]"}.mw-parser-output .navbar li{word-spacing:-0.125em}.mw-parser-output .navbar a>span,.mw-parser-output .navbar a>abbr{text-decoration:inherit}.mw-parser-output .navbar-mini abbr{font-variant:small-caps;border-bottom:none;text-decoration:none;cursor:inherit}.mw-parser-output .navbar-ct-full{font-size:114%;margin:0 7em}.mw-parser-output .navbar-ct-mini{font-size:114%;margin:0 4em}html.skin-theme-clientpref-night .mw-parser-output .navbar li a abbr{color:var(--color-base)!important}@media(prefers-color-scheme:dark){html.skin-theme-clientpref-os .mw-parser-output .navbar li a abbr{color:var(--color-base)!important}}@media print{.mw-parser-output .navbar{display:none!important}}

/* end https://en.wikipedia.org/ */

</style><div id="Software_design_patterns225" style="font-size:114%;margin:0 4em"><a href="Software_design_pattern" title="Software design pattern">Software design patterns</a></div></th></tr><tr><th scope="row" class="navbox-group" style="width:1%"><a href="Design_Patterns" title="Design Patterns">Gang of Four<br>patterns</a></th><td class="navbox-list-with-group navbox-list navbox-odd hlist" style="width:100%;padding:0"><div style="padding:0 0.25em"></div><table class="nowraplinks navbox-subgroup" style="border-spacing:0"><tbody><tr><th scope="row" class="navbox-group" style="width:1%"><a href="Creational_pattern" title="Creational pattern">Creational</a></th><td class="navbox-list-with-group navbox-list navbox-odd" style="width:100%;padding:0"><div style="padding:0 0.25em">

<ul><li><a href="Abstract_factory_pattern" title="Abstract factory pattern">Abstract factory</a></li>

<li><a href="Builder_pattern" title="Builder pattern">Builder</a></li>

<li><a href="Factory_method_pattern" title="Factory method pattern">Factory method</a></li>

<li><a href="Prototype_pattern" title="Prototype pattern">Prototype</a></li>

<li><a href="Singleton_pattern" title="Singleton pattern">Singleton</a></li></ul>

</div></td></tr><tr><th scope="row" class="navbox-group" style="width:1%"><a href="Structural_pattern" title="Structural pattern">Structural</a></th><td class="navbox-list-with-group navbox-list navbox-even" style="width:100%;padding:0"><div style="padding:0 0.25em">

<ul><li><a href="Adapter_pattern" title="Adapter pattern">Adapter</a></li>

<li><a href="Bridge_pattern" title="Bridge pattern">Bridge</a></li>

<li><a href="Composite_pattern" title="Composite pattern">Composite</a></li>

<li><a href="Decorator_pattern" title="Decorator pattern">Decorator</a></li>

<li><a href="Facade_pattern" title="Facade pattern">Facade</a></li>

<li><a href="Flyweight_pattern" title="Flyweight pattern">Flyweight</a></li>

<li><a href="Proxy_pattern" title="Proxy pattern">Proxy</a></li></ul>

</div></td></tr><tr><th scope="row" class="navbox-group" style="width:1%"><a href="Behavioral_pattern" title="Behavioral pattern">Behavioral</a></th><td class="navbox-list-with-group navbox-list navbox-odd" style="width:100%;padding:0"><div style="padding:0 0.25em">

<ul><li><a href="Chain-of-responsibility_pattern" title="Chain-of-responsibility pattern">Chain of responsibility</a></li>

<li><a href="Command_pattern" title="Command pattern">Command</a></li>

<li><a href="Interpreter_pattern" title="Interpreter pattern">Interpreter</a></li>

<li><a href="Iterator_pattern" title="Iterator pattern">Iterator</a></li>

<li><a href="Mediator_pattern" title="Mediator pattern">Mediator</a></li>

<li><a href="Memento_pattern" title="Memento pattern">Memento</a></li>

<li><a href="Observer_pattern" title="Observer pattern">Observer</a></li>

<li><a href="State_pattern" title="State pattern">State</a></li>

<li><a href="Strategy_pattern" title="Strategy pattern">Strategy</a></li>

<li><a href="Template_method_pattern" title="Template method pattern">Template method</a></li>

<li><a href="Visitor_pattern" title="Visitor pattern">Visitor</a></li></ul>

</div></td></tr></tbody></table><div></div></td></tr><tr><th scope="row" class="navbox-group" style="width:1%"><a href="Concurrency_pattern" title="Concurrency pattern">Concurrency<br>patterns</a></th><td class="navbox-list-with-group navbox-list navbox-even hlist" style="width:100%;padding:0"><div style="padding:0 0.25em">

<ul><li><a href="Active_object" title="Active object">Active object</a></li>

<li><a href="Balking_pattern" title="Balking pattern">Balking</a></li>

<li><a href="Binding_properties_pattern" title="Binding properties pattern">Binding properties</a></li>

<li><a href="Double-checked_locking" title="Double-checked locking">Double-checked locking</a></li>

<li><a href="Asynchronous_method_invocation" title="Asynchronous method invocation">Event-based asynchronous</a></li>

<li><a href="Guarded_suspension" title="Guarded suspension">Guarded suspension</a></li>

<li><a href="Monitor_(synchronization)" title="Monitor (synchronization)">Monitor</a></li>

<li><a href="Proactor_pattern" title="Proactor pattern">Proactor</a></li>

<li><a href="Readers%E2%80%93writer_lock" title="Readers–writer lock">Read–write lock</a></li>

<li><a href="Scheduler_pattern" class="mw-redirect" title="Scheduler pattern">Scheduler</a></li>

<li><a href="Scheduled-task_pattern" title="Scheduled-task pattern">Scheduled-task pattern</a></li>

<li><a href="Semaphore_(programming)" title="Semaphore (programming)">Semaphore</a></li>

<li><a href="Thread_pool" title="Thread pool">Thread pool</a></li>

<li><a href="Thread-local_storage" title="Thread-local storage">Thread-local storage</a></li></ul>

</div></td></tr><tr><th scope="row" class="navbox-group" style="width:1%"><a href="Architectural_pattern" title="Architectural pattern">Architectural<br>patterns</a></th><td class="navbox-list-with-group navbox-list navbox-odd hlist" style="width:100%;padding:0"><div style="padding:0 0.25em">

<ul><li><a href="Front_controller" title="Front controller">Front controller</a></li>

<li><a href="Interceptor_pattern" title="Interceptor pattern">Interceptor</a></li>

<li><a href="Specification_pattern" title="Specification pattern">Specification</a></li>

<li><a href="Publish%E2%80%93subscribe_pattern" title="Publish–subscribe pattern">Publish–subscribe</a></li>

<li><a href="Naked_objects" title="Naked objects">Naked objects</a></li>

<li><a href="Service_locator_pattern" title="Service locator pattern">Service locator</a></li>

<li><a href="Active_record_pattern" title="Active record pattern">Active record</a></li>

<li><a href="Identity_map_pattern" title="Identity map pattern">Identity map</a></li>

<li><a href="Data_access_object" title="Data access object">Data access object</a></li>

<li><a href="Data_transfer_object" title="Data transfer object">Data transfer object</a></li>

<li><a href="Inversion_of_control" title="Inversion of control">Inversion of control</a></li>

<li><a href="JSP_model_2_architecture" title="JSP model 2 architecture">Model 2</a></li>

<li><a href="Broker_pattern" title="Broker pattern">Broker</a></li></ul>

</div></td></tr><tr><th scope="row" class="navbox-group" style="width:1%">Other<br>patterns</th><td class="navbox-list-with-group navbox-list navbox-even hlist" style="width:100%;padding:0"><div style="padding:0 0.25em">

<ul><li><a href="Blackboard_design_pattern" class="mw-redirect" title="Blackboard design pattern">Blackboard</a></li>

<li><a href="Business_delegate_pattern" title="Business delegate pattern">Business delegate</a></li>

<li><a href="Composite_entity_pattern" title="Composite entity pattern">Composite entity</a></li>

<li><a href="Dependency_injection" title="Dependency injection">Dependency injection</a></li>

<li><a href="Guard_(computer_science)" title="Guard (computer science)">Guard clause</a></li>

<li><a href="Intercepting_filter_pattern" title="Intercepting filter pattern">Intercepting filter</a></li>

<li><a href="Lazy_loading" title="Lazy loading">Lazy loading</a></li>

<li><a href="Mock_object" title="Mock object">Mock object</a></li>

<li><a href="Null_object_pattern" title="Null object pattern">Null object</a></li>

<li><a href="Object_pool_pattern" title="Object pool pattern">Object pool</a></li>

<li><a href="Servant_(design_pattern)" title="Servant (design pattern)">Servant</a></li>

<li><a href="Type_Tunnel_pattern" class="mw-redirect" title="Type Tunnel pattern">Type tunnel</a></li>

<li><a href="Method_chaining" title="Method chaining">Method chaining</a></li>

<li><a href="Delegation_pattern" title="Delegation pattern">Delegation</a></li></ul>

</div></td></tr><tr><th scope="row" class="navbox-group" style="width:1%">Books</th><td class="navbox-list-with-group navbox-list navbox-odd hlist" style="width:100%;padding:0"><div style="padding:0 0.25em">

<ul><li><i><a href="Design_Patterns" title="Design Patterns">Design Patterns</a></i></li>

<li><i><a href="Enterprise_Integration_Patterns" title="Enterprise Integration Patterns">Enterprise Integration Patterns</a></i></li></ul>

</div></td></tr><tr><th scope="row" class="navbox-group" style="width:1%">People</th><td class="navbox-list-with-group navbox-list navbox-even hlist" style="width:100%;padding:0"><div style="padding:0 0.25em">

<ul><li><a href="Christopher_Alexander" title="Christopher Alexander">Christopher Alexander</a></li>

<li><a href="Erich_Gamma" title="Erich Gamma">Erich Gamma</a></li>

<li><a href="Ralph_Johnson_(computer_scientist)" title="Ralph Johnson (computer scientist)">Ralph Johnson</a></li>

<li><a href="John_Vlissides" title="John Vlissides">John Vlissides</a></li>

<li><a href="Grady_Booch" title="Grady Booch">Grady Booch</a></li>

<li><a href="Ward_Cunningham" title="Ward Cunningham">Ward Cunningham</a></li>

<li><a href="Martin_Fowler_(software_engineer)" title="Martin Fowler (software engineer)">Martin Fowler</a></li>

<li><a href="Robert_C._Martin" title="Robert C. Martin">Robert Martin</a></li>

<li><a href="Jim_Coplien" title="Jim Coplien">Jim Coplien</a></li>

<li><a href="Douglas_C._Schmidt" title="Douglas C. Schmidt">Douglas Schmidt</a></li>

<li><a href="Linda_Rising" title="Linda Rising">Linda Rising</a></li></ul>

</div></td></tr><tr><th scope="row" class="navbox-group" style="width:1%">Communities</th><td class="navbox-list-with-group navbox-list navbox-odd hlist" style="width:100%;padding:0"><div style="padding:0 0.25em">

<ul><li><a href="The_Hillside_Group" title="The Hillside Group">The Hillside Group</a></li>

<li><a href="Portland_Pattern_Repository" title="Portland Pattern Repository">Portland Pattern Repository</a></li></ul>

</div></td></tr><tr><th scope="row" class="navbox-group" style="width:1%">See also</th><td class="navbox-list-with-group navbox-list navbox-even hlist" style="width:100%;padding:0"><div style="padding:0 0.25em">

<ul><li><a href="Anti-pattern" title="Anti-pattern">Anti-pattern</a></li>

<li><a href="Architectural_pattern" title="Architectural pattern">Architectural pattern</a></li></ul>

</div></td></tr></tbody></table></div></div><div><div class="zim-footer">

This article is issued from <a class="external text" title="Last edited on 2025-02-03" href="https://en.wikipedia.org/wiki/?title=Reactor_pattern&oldid=1273597222">Wikipedia</a>. The text is available under <a class="external text" href="https://creativecommons.org/licenses/by-sa/4.0/deed.en">Creative Commons Attribution-Share Alike 4.0</a> unless otherwise noted. Additional terms may apply for the media files.

</div>

</div></div>

</div>

</main>

</div>

</body></html>